As system-on-a-chip (SOC) designs get more and more complex, functional verification is becoming the dominant task in the development process. Many case studies have shown that functional verification consumes 40 to 70 percent of the overall engineer-weeks for SOC projects. Many companies hire (or try to hire!) two verification engineers for every design engineer on a project team. Accelerating the verification process is critical for meeting ever-tightening time-to-market requirements.

It's interesting to consider the importance of functional verification in light of the trend toward more design reuse on SOC projects. Design reuse, including the license of virtual components (VCs) from intellectual property (IP) vendors, has played a significant role in reducing the design time portion of large projects. However, reducing design time without reducing verification time produces only limited improvements in the overall project schedule. In fact, effective design reuse can increase the percentage of project effort spent on functional verification while reducing the overall development time.

Consider the results of a design case study reported by Nortel at DesignCon98 (see Figure 1). These results are fairly typical for SOC projects; functional verification via a combination of simulation and emulation consumed two-thirds of the development time, as measured in engineer-weeks. A small amount of time was spent on synthesis, timing analysis, and other structural activities, and only about a quarter of the time was spent on the RTL design. Even if design reuse were able to shrink the design time on such a project to zero, only a quarter of the development time would be saved and functional verification would have grown from 61 percent to 83 percent of the total effort.

Figure 1 - Time spent in chip development.

Functional verification, via a combination of simulation and emulation, consumed two-thirds of the development time in a case study by Nortel.

Guaranteeing success

One of the reasons that design reuse has been effective at reducing SOC development times is the set of specifications available from the Virtual Socket Interface Alliance (VSIA). VSIA was founded in 1996 to define ways to speed integration of virtual components from both internal and external sources. More than 200 companies have contributed to the development of the specifications and other documents that cover terminology, methodology, design data file formats, and deliverables for VCs. VSIA also plays a critical role in documenting best practices and guidelines for VC providers and in defining expectations for VC integrators.

Recognizing the importance of accelerating verification for VC-based SOC designs, VSIA established the Verification Development Working Group (DWG) in 1999. This group's charter is to define the set of deliverables from the VC provider to the VC integrator to enable the verification of the correct operation of the VC (as specified) in the SOC. This includes the verification of the stand-alone VC, of the interface between the VC and the rest of the SOC, and of the SOC itself.

Although this charter encompasses other forms of VC and SOC verification, the DWG members decided to focus on functional verification initially because this activity often dominates the overall development cycle. The DWG membership has included representatives from VC providers and EDA vendors as well as systems and semiconductor companies active in SOC design. Participating companies have included ARM, BOPS, Cadence, Fujitsu, Motorola, Palmchip, Synopsys, Verisity, and O-In Design Automation.

The current DWG plan calls for the development and release of two documents related to functional verification-a reference document and a deliverables specification. The reference is intended to establish a common vocabulary for discussing functional verification by

categorizing and defining a wide range of methods in use today. Examples of methods include the following:

• Dynamic verification techniques such as deterministic simulation, random pattern simulation, hardware acceleration and hardware modeling

• Static (formal) verification techniques such as model checking and theorem proving

• Static/dynamic hybrid techniques such as semi-formal verification

• System-level techniques such as emulation and hardware-software co-verification

• Verification metrics such as code coverage and functional coverage

• Equivalence verification of multiple design representations

• Prototyping and other physical realizations of the design

The reference document will define these terms-and many others as well-and will explain the relationships between these different verification techniques and tools. This material is an essential precursor to the second document, a specification that will define the verification-related deliverables that a VC provider supplies along with the VC itself to the VC integrator. Some deliverables will be classified as mandatory, some will be recommended, some will be optional, and some will make sense only for certain kinds of VCs.

As an example of a deliverable relevant only in some cases, a simulation model might be considered mandatory for a hard VC, but optional for a soft (RTL) VC since the RTL itself can run in simulation. Some would argue that a faster simulation-only model should be recommended for a soft VC. Others would argue that it isn't recommended because there should be only one "golden source" model for the VC. As another example, an instruction-set simulator (ISS) might be recommended for a microprocessor or DSP but probably doesn't apply to other types of VCs.

Consider the sources

Consider a representative VC and some of the verification-related deliverables that might accompany it as part of the package shipped by the VC provider to the VC integrator (see Figure 2). Elements of the overall verification environment would typically include transaction generators to stimulate the VC, results comparison for VC responses, simulation test scripts to verify VC operation, protocol monitors to check for legal behavior on interfaces, and embedded checkers to check for legal behavior on internal design structures. Other elements might support formal and semi-formal verification. The Verification DWG's task is to clearly define which of these elements make sense for specific VCs and which elements should be delivered to the integrator.

Figure 2 - Typical elements of a VC verification environment

A representative VC and some of the accompanying verification-related deliverables that might accompany a part of the package shipped by the VC provider to the VC integrator.

There are three major reasons to define VC deliverables related to functional verification. The first two are relevant for any VSIA deliverables specification. First, defining deliverables establishes best practices for VC providers. A VC provider should always deliver the mandatory items; a better VC provider will include some of those recommended. Second, knowing the deliverables and best practices allows the VC integrator to better evaluate different VC providers by how well they followed the specification. Just knowing what questions to ask a potential provider can be critical in VC selection.

Defining the elements

Finally, the deliverables document defines those elements of the VC provider's stand-alone VC functional verification environment that may be useful for the VC integrator. There are a number of reasons why a VC integrator may want reusable verification elements accompanying the VC. The integrator may want to rerun at least some portion of the stand-alone VC verification suite on-site to double-check the verification process.

Especially for a hard VC, the integrator may want to leverage this suite to provide VC-targeted vector sequences for manufacturing test purposes.

For a soft VC, the integrator may not be able to resist the temptation to customize the VC. "Reuse without rework" is a good target for wider adoption of VCs, but the reality is that soft VCs are quite often modified. In such a case, the VC integrator will want to re-run appropriate portions of the VC verification suite on the modified VC to validate the changes and ensure that nothing was broken in the process.

The VC integrator would also generally like to leverage the VC verification elements and verification suite in the context of the full SOC. This is a tough problem to solve, since the transaction generators and results checkers that support stand-alone VC verification are replaced by surrounding logic when the VC is integrated into the SOC. Some forms of deliverables, such as verification suites in transaction form rather than as binary vectors, can make it easier to adapt the VC verification suite to run on the SOC and re-verify the core in a full-chip context.

Both the VC provider and the VC integrator have a vested interest in ensuring that the VC is being used properly in the SOC. The integrator connects the VC to the rest of the chip by using a set of signals known as the "application interface" and the integrator must use this interface properly. The rules for using an application interface can be quite complicated and hard to understand from a paper specification, so the delivery of a protocol monitor that runs in simulation and reports any misuse of the application interface signals is desirable.

Additional monitors or embedded checkers that watch for problems internal to the VC-such as data corruption and state machine misbehavior-can also alert the integrator to problems with the VC itself or with the way that the VC is being used.

The deliverables

Additional deliverables are needed if the VC provider uses formal or semi-formal verification and wants to allow the VC integrator to rerun or leverage this verification. Deliverables might include assertions to be verified, which might be derived from embedded checkers, and a definition of legal application interface input behavior, which might be derived from the application interface protocol monitor.

Additional deliverables may also be needed if the VC integrator is using hardware-software co-verification to verify the functionality of the VC as well as the overall SOC with various integrated VCs. In such a case, these deliverables might include stimulus test programs or a hardware abstraction layer library, which can be very useful in verifying the correct operation of the VC in the SOC as well as the interface to the rest of the system.

The verification elements delivered along with the VC enable various forms of verification reuse by allowing the VC integrator to leverage the stand-alone VC functional verification effort. Indeed, experienced VC integrators often argue that design reuse isn't effective without companion verification reuse. In recognition of this importance, the VSIA Verification DWG is hard at work on the reference and deliverables documents described above. Additional members are always welcome. The more good ideas-the better the final result.

Tom Anderson and Robin Bhagat are co-chairs of the VSIA Verification Development Working Group. Tom Anderson is currently vice president of applications engineering at O-In Design Automation, Inc. and was formerly vice president of engineering at Virtual Chips, Inc. Robin Bhagat is vice president, SOC technology at Palmchip Corp.